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"Multichannel synchronised communication 



The invention relates to a method of transferring data from a sender process to a 
5 plurality of receiver processes, at least some of which are described in a hardware 
description language, and to hardware produced in accordance with such a method. 

Occam is a computer language in which some parts of a program may be made 
to run concurrently (see Inmos Ltd., The Occam2 Reference Manual, Prentice-Hall 

10 International, 1988). The parts are called processes. The programmer may declare 
synchronous channels. Each channel connects exactly two processes in such a way that 
data can be sent from one (the sender process) to the other (the receiver process) 
synchronously. That is, if the sender starts to send first it must wait until the receiver is 
ready to receive, likewise if the receiver tries to receive first it must wait until the sender 

15 is ready to send. 

Therefore data is never lost by (say) the sender overwriting a previous message 
before the receiver receives it; and never received twice by (say) the receiver 
performing a receive twice without the sender updating the content of the channel in 
20 between. 



CHAN OF INT ch: — declare ch as an integer channel 
25 PAR 

SEQ — first process 

— do some things 

ch ! x — send the value x down channel ch 

— do some more things 

30 SEQ — second process (in parallel with first) 



For example, in Occam: 



— do some things 
ch ? y — receive a value from channel ch, and store in y 
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. ... —do some more things 

The concrete syntax for send and receive may vary in other languages, for 
example send (ch, x) instead of ch ! x or y = receive (ch) instead of ch ? y. However the 
communication is always between precisely two processes. 

VHDL is a hardware description language, which is also used extensively for 
hardware synthesis (see Steve Carlson, Introduction to HDL-based Design Using 
VHDL, Synopsys Inc., CA, 1991 and IEEE Standard VHDL Language Reference 
Manual, IEEE Std 1076-1993, IEEE, New York, 1993). Concurrent VHDL processes 
communicate by unsynchronised shared signals. One writer process (analogous to a 
sender) may write a value to a signal, and one or several readers (analogous to 
receivers) may read that value. However, it is entirely up to the designer to ensure that 
written data is read when it is valid by the readers. This can be done by building an 
handshake protocol, so that readers write to another signal (dedicated to this purpose) to 
indicate their status with regard to the data transfer. 

For example, in VHDL you assign the value of an expression E to a signal S 
with the construct S <= E, and read from a signal S just by using its name in an 
expression. There is no limit to how many processes may read from S (although only 
one may write to S unless the signal is declared with a resolution function). However 
there is no automatic synchronisation. Values may be read more often than written (and 
so data repeated) or written more often than read (and so data lost). 

Bach (see British Patent Publication No. 2317245) is a language similar to the 
software language of C, but which supports parallelism and communication like Occam, 
and which may be used to synthesise hardware. (Because of this feature, the Bach 
compiler which compiles the Bach language into hardware is called a hardware 
compiler). That is, the syntax is like C (with extensions), but the semantics are more 
akin to Occam, with its parallelism and synchronised communication. In Bach data 
may be sent along synchronous channels as in Occam. 
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Note particularly that communication is always one to one. One process sends, 
and another process receives. To send data to more processes requires more channels. 

In addition there are global variables, which may be written and read by several 
processes, but without automatic synchronisation. It is possible to use shared variables 
to distribute information to several processes, but then there is no guaranteed 
synchronisation, and the user must invent an ad-hoc signalling system to ensure data is 
correctly transferred. In Bach such shared variables are called achans for asynchronous 
channels. 

For example, in Bach: 

Void main (void) 



{ 



chan int ch: 



// declare ch as a synchronised channel carrying 
// integer data 



par {{ 



// first process 



// do some things 



send (ch, x); 



// send the value x down channel ch 



// do some more things 




(in parallel with first) 
// do some things 

// receive a value from channel ch, and store in y 
// do some more things 



y = receive (ch); 



} 



The Bach compilers convert these constructs either into software for execution 
on a microprocessor or into a hardware description for the design of a special purpose 
integrated circuit. 
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According to the invention there is provided a method of transferring data from 
a sender process to a plurality of receiver processes, wherein at least one of said 
processes is described in a hardware description language, said hardware description 
language incorporating simulation means for simulation of the behaviour of hardware 
and also incorporating a hardware compiler for deriving hardware which behaves 
according to said simulation, and wherein the method uses a language construct which 
effects synchronised communication between the sender process and the receiver 
processes. 

The method may involve carrying out a send algorithm under the control of a 
pre-emptive scheduler. 

The scheduler may ensure that the send algorithm is carried out without 
descheduling. 

A check may be made that all of the receiver processes are ready to receive data 
before data is transferred from the sender process to the receiver processes. 

The method may involve carrying out a receive algorithm under the control of a 
pre-emptive scheduler. 

The scheduler may ensure that the receive algorithm is carried out without 
descheduling. 

At least one of said processes may be embodied in hardware. 

This is the so-called "hybrid" hardware-software implementation of the 
invention. 
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Alternatively all of said processes may be described in said hardware description 
language. 

The invention also provides a synchronous electrical circuit produced by first 
simulating at least part of the circuit in accordance with the above method and then 
creating the circuit using said hardware compiler. 

The synchronous electrical circuit may be a digital electronic circuit. 

The invention also provides a hardware description language adapted to simulate 
the behaviour of at least a sender process and a plurality of receiver processes, and 
comprising a language construct which effects synchronised communication between 
the sender process and the receiver processes. 

The hardware description language may be adapted to carry out the above 
method. 

In this way it is possible to extend a language like Bach to support what we 
herein call multi-channels, or mchans for short. A multi-channel is synchronous like an 
Occam channel, and permits multiple receivers like a VHDL signal. 

We provide implementations in both software and hardware, so that a designer 
can simulate a design in software before synthesising it in hardware, using the same 
design document. The hardware implementation involves creating a synchronisation 
block capable of synchronising an arbitrary (but fixed) number, n > 0, of processes (one 
sending, n - 1 receiving), and protocols which each sender or receiver must obey when 
performing. Possible implementations are given later. 

We add an extra data type specifier (arbitrarily given the name mchan) to the 
description language. For example, in Bach: 



10 
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mchan int ml; 
par {{ 

send (ml, x); 



y = receive (ml); 



z = receive (ml): 



15 



}} 



// declare ml as an 'int 1 type 

// multichannel 

// begin process branching 

// code for process 1 

// send value of x on ml, and synch 

// more code for process 1 

// code for process 2 

// synchronise on ml, store value in y 

//more code for process 2 

// code for process 3 

// synchronise on ml, store value in z 

// more code for process 3 

// end process branching 



This example shows the declaration of a multichannel ml, and three processes 
which use it. The sender sends the result of any expression E to ml with the phrase 
send (ml, E);. In this case there are two receivers, and they may obtain the value sent 
20 by using the expression receive (ml). The send and receive constructs will not 
terminate until the entire synchronisation is complete; that is, when the sender has 
executed send and all receivers have executed receive). 

In addition any receiver may use the 'ready 1 test, ready (ml) which is true if the 
25 sender has executed send but is still waiting for the synchronisation. The 'ready 1 test 
finishes immediately (it doesn't wait for synchronisation) and it doesn't affect the 
behaviour of the other processes engaged in the synchronisation. 

Suppose ml is declared as a multichannel. Not every process is required to be a 
30 sender or receiver for ml; this allows synchronisation of just a subset of processes. 
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Only one process may be a sender for it, and this process is identified by the 
compiler as being the only one containing a send command for ml. Several processes 
may be receivers for ml, and these are identified as those processes containing the 
expression receive (ml). No process may be both sender and receiver for ml. 



This multichannel language primitive (ie. Additional part to the language) makes 
it easy for a designer to specify that a single process (software or circuit) controls and 
synchronises data transfer with a number of dependent processes (software or circuits). 



The implementation is cheaper than would be the set of at least N + 1 one-to-one 
synchronous sends that would be required in Occam (where N is the number of 
15 receivers) or in Bach. The new method is therefore faster, and may require less silicon 
area (in a hardware implementation) or memory (in a software implementation). 

Because hardware and software implementations are available multichannels can 
be added to a hardware compilation system such as Bach. 



The invention will now be more particular described, by way of example only, 
with reference to the accompanying drawings, in which: 

Figures 1(a), 1(b) and 1(c) show high level views of channels and signals; 



5 



10 



The designer does not need to build an ad-hoc synchronising circuit each time as 



in VHDL. 



20 



25 



Figure 2 gives an algorithm for handling sends on mchannels; 



Figure 3 gives an algorithm for handling receives on mchannels; 



30 



Figure 4 gives a simpler version of the algorithm in Figure 3 which is used when 
the data to be received on an mchannel is not used; 
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Figure 5 shows one implementation of mchannel send in hardware, giving a state 
machine; 



Figure 6 shows one implementation of mchannel receive in hardware, giving a 
state machine; and 

Figure 7 shows one hardware implementation of the mchannel synchronisation 
block 6 of Figure 1(c), giving a possible digital circuit. 

Figure 1(a) is a high level view of a synchronous channel of the type used in 
Occam and Bach. A sender process 2 is connected to a receiver process 4 via a 
synchronisation block 6. There is one sender 2 and one receiver 4, and these are 
synchronised. 

Throughout Figures 1(a) to 1(c) synchronisation signals 8 are represented by 
small arrows, and data signals 10 are represented by larger arrows. 

Figure 1(b) is a high level view of a VHDL signal. For convenience the same 
reference numbers are used to indicate the sender (or writer) process 2, the receiver (or 
reader) processes 4, and the data signals 10. The processes are unsynchronised. 

Figure 1(c) is a high level view of a multichannel in accordance with the 
invention. For convenience the same reference numbers are used to indicate the sender 
process 2, the receiver processes 4, the synchronisation block 6, and the synchronisation 
signals 8 and data signals 10. The processes (2 and 4) are synchronised by the 
synchronisation block 6. 

Software implementations of the invention will be described first, followed by 
hardware implementations. 
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Algorithms for handling send and receive on mchannels will be described. 
These algorithms are intended for execution on a sequential computer which has a 
single processor. Some concepts and terms will first be explained: 

Each process is assigned a number called a process identifier (id for short). No 
two processes have the same id. 

Throughout, we will assume that the execution of processes is managed by a 
pre-emptive scheduler. Such a pre-emptive scheduler controls the time division of the 
execution of various processes. For example, processing can be shared between 
different processes, or the scheduler can instruct that a given process be completed 
before processing of the next process begins. Two procedures (or commands, i.e. 
"lock" and "unlock") are provided to interact directly with the scheduler: lockQ instructs 
it not to deschedule the current process, and unlockQ passes control back to it to run 
another (or possibly the same) process. That is, everything between lock and unlock 
must be executed before any other process is executed. A set is used to store the 
processes which are ready to run. The scheduler dispatches items from it and terminates 
when there are no items left. Two procedures (or commands) will be used to update the 
set: "wake-up" adds process ids and "sleep" removes the id of the process currently 
being executed. Note that "wake up" and "sleep" do not perform any scheduling or 
descheduling, they simply affect which processes are available to be scheduled when 
the scheduler next runs. 

Certain information about mchannels must be stored. A convenient way of 
doing this is to use the following functions: 

channel-ready : returns true if either a send or a receive has happened on a given 
mchannel, and returns false otherwise. 

data : returns the data most recently sent on a given mchannel. 



M&C Folio No P506 15GB 10 ^ 

It is also necessary to find out which sends and receives have happened. The 
following functions will be used for this purpose: 



sender : if a send has happened on a given mchannel, this function returns the 
process id in which the send can be found. 

receivers : given an mchannel, this function returns the ids of the processes 
whose receives have happened. 

Variables used to receive data from an mchannel will be called destinations. For 
example, in the assignment x = receive (ch), x is the destination. Not all receives have 
destinations, however. For example, in the fragment of code 

{ 

send (chl, d); 
receive (ch2); 

} 

receive does not have a destination. Such receives are used for synchronisation. Given 
an mchannel, the function destinations returns all the destinations in the processes 
whose receives have happened. 

As has already been mentioned, each send operation on an mchannel typically 
has several corresponding receives. It is useful for our purposes to know the ids of 
processes in which the receives exist. The following can be used to find out this 
information. 

receives-on-mchannel returns the ids of the processes which receive on a given 
mchannel. 
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All of the functions we have presented will be viewed extensionally, i.e. as sets 
of pairs. For example, the function which maps 1 to 2, 2 to 3, 3 to 4 and 4 to 1 can be 
written as f = {(1,2), (2,3), (3,4), (4,1)} 

The algorithms will be presented in the form 

procedure-name (parameter list) — 
procedure-body 

The procedure-body consists of assignments to the functions introduced above as well 
as calls to the following procedures: lock, unlock, wake-up f sleep and copy-data-to- 
destinations. The purpose of copy-data-to-destinations is, as its name suggests, to copy 
a given piece of data to the destinations of a given mchannel: 



copy-data-to-destinations (d t ch) = 
for each x in destinations (ch) 
do 

x ;= d 
od 

The functions are not passed as arguments. Instead we assume that there is a global 
state in which they exist. The reason for making this assumption is to simplify the 
presentation. 

We now focus our attention on the assignments. These assignments involve 
updating the functions introduced above. Set-theoretic operations can be used to 
perform the updates, since the functions are sets of pairs. In particular, we will make 
use of the following: 



(a) union, written kj, for combining two sets. For example: {1,2,3} kj {2,3,4,5} = 
{1,2,3,4,5}; 
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(b) difference, written -, for removing items from a set. For example: {1,2,3} - 
{2,3,4,5} = {1}; 

(c) domain co-restriction, written < (in the figures the same symbol is used, except 
that it has a horizontal line through the centre), for removing pairs whose first 
component is in a given set. For example taking the set of pairs "f ' given above, 
then {1,2} < /does not map 1 and 2 to anything. 

(d) function override, written ©, for modifying a function. To illustrate this, 
consider the function / again. If we want / to map 1 to 3 (instead of mapping 1 to 
2), we could write/© {(1,3)}. 

Two further symbols from set theory will be used: # and 0. The first of these 
returns the number of items in a set, and the other stands for the empty set. 

We are now in a position to present our algorithms for send and receive. The 
algorithm for send, shown in Figure 2, is the simpler of the two, and so will be 
described first. It consists of four parts: 

(1) First the scheduler is instructed not to deschedule the current process (box 1 1) 

(2) The id of the process containing the send and the data to be sent are both 
recorded. The mchannel on which the data is to be sent is set to READY (box 
12). 

(3) Next a check is made to see whether all of the receives have happened (i.e. all of 
the receivers are ready to receive) (box 13). If they have, the data can be 
received by all of the receivers. This entails the following (box 14): 

copying data to the destinations; 

putting the current process to sleep and waking up all of the receivers; 
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resetting the information stored about the mchannel, i.e. setting the 
mchannel to NOT READY and clearing each of the following: the data 
sent on the mchannel, the destinations for the mchannel, the sender for 
the mchannel, the receivers for the mchannel. 

the process is then put to sleep. 

If there are still receives to arrive, however, the process has more work to do at 
later time and so is put to sleep (box 15). 

(4) Finally, control is handed back to the scheduler so that it can select another 
process (if any) to run. 

The algorithm is given below: 

send(pid, d, ch) = 
lockQ; 

sender ™ sender yj {(ch, pid)} ; 
channel-ready channel-ready © {READY} ; 
data ~ data u {(ch, d)}; 

if # receivers (ch) = # (receives-on-mchannel (ch)) 
then copy-data-to-destinations (d, ch); 
wake-up (receivers (ch)); 

channel-ready := channel-ready © {(ch, NOT READY)}; 
data := {ch} < data; 

destinations := destinations © {(ch, 0)}; 

sender := {ch} < sender; 

receivers := {ch} < receivers; 

sleepQ; 
else sleep (); 
unlockQ 
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The algorithm for receive is more involved, and is shown in Figure 3. Once 
again, it consists of four parts: 

(1) first the scheduler is instructed not to deschedule the current process (box 16) 

(2) the id of the process containing the receive is recorded and so is the destination 
(box 17). (If there happens to be no destination, destination does not need to be 
updated.) 

(3) next, a check is made (box 18) to see whether the following conditions are 
satisfied: the mchannel is ready and all of the receives have happened. If both of 
them are satisfied, it means that a send has happened (and so data is waiting to 
be received) and all of the receives are ready to receive. Thus it is safe to 
receive data. This entails the following (box 19): 

- copying the data to the destinations; 

- waking up the process which sent the data; 

- waking up the receivers, except the one that has just happened; 

- resetting the channel (same as in the send algorithm) 

- the process is then put to sleep. 

If either one of the two conditions does not hold, the process is put to sleep (box 
21). 

(4) Control is handed back to the scheduler. 

The algorithm for receive is given below: 
receive (ch, pid, y) — 
lockQ; 

receivers := receivers © {(ch, receivers {ch) u {pid})}; 

destinations := destinations © {(ch, destinations (ch) {y})}; 

if channel-ready (ch) & # receivers (ch) = # receives-on-mchannel (ch) 
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then copy-data-to-destinations {data (ch), ch); 
wake-up (sender (ch)); 
wake-up (receivers (ch) - {pid}); 

channel-ready := channel-ready © {(ch, NOT READY)}; 

data := {ch} < data; 

destinations := destinations © {(ch 9 0)}; 

sender := {ch} < sender; 

receivers := {ch} < receivers; 

sleep 0; 
else sleep 0; 
unlock 0 

As mentioned above, a receive may have no destination. The algorithm for 
receive can be simplified to cater for this situation, as shown in Figure 4. Here is the 
simplified algorithm: 

receive! (ch, pid) — 
lockQ; 

receivers :— receivers © {(c/z, receivers (ch) kj {pid})}; 
if channel-ready (ch) & # receivers (ch) = # receives-on-mchannel (ch) 
then copy-data-to-destinations (data (c/z), ch); 

wake-up (sender (ch)); 

wake-up (receivers (ch) - {pid}); 

channel-ready := channel-ready © {(ch, NOT READY)} ; 

data := {ch} < data; 

destinations := destinations © {(ch, 0)}; 

sender := {ch} < sender; 

receivers := {ch} < receivers; 

sleepQ; 
else sleepQ; 
unlockQ 
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A hardware implementation will now be described. This uses a synchronous 
clock common to all the processes. 

Figure 5 shows the hardware implementation of a send operation, as a state 
machine. In the first state the value to be sent by sender 20 is connected to the data 
wires 21. Next the sr (sender ready) signal on the sender ready output 22 is set true, to 
indicate that the data is valid. In state 3 the sender waits until the synch signal on the 
synch input 24 is true. Then it sets sr back to false, ready for the next communication. 
Finally, it may continue with its normal operation. States 1 and 2 may be completed in 
the same clock cycle. Step 4 must occur after the start of the cycle in which synch is 
true, and before the start of the next cycle. 

Figure 6 shows the hardware implementation of the zth receive operation. In the 
first state the receiver 26 sets its individual receiver ready signal rr, on receiver ready 
output 28 to true. Then it waits for the shared synch signal on synch input 30 to go true. 
In the next clock cycle it must transfer the data value from the data wires 32, and set the 
rri signal back to false. Then it may continue with normal operation. 

Figure 7 shows the hardware implementation of the synchronisation block 34 
used in the hardware implementation. The data signal on date wires (21, 32) is passed 
straight through and distributed to all the receivers 26. The sender ready signal sr on 
sender ready input 36 and receiver ready signals rr,- on receiver ready outputs 38 for all 
receivers 1 . . .N are combined by logical AND gate 40. The result is a signal called 
synch and is passed to the sender and all the receivers on synch outputs 42. 

Finally, if the ready test function is used by one or more of the receivers 26, then 
the sr signal must be distributed to all receivers 26 which do so. The value of the test 
ready (m) on this channel at any moment is equal to the value of the signal sr. 

Note that in addition a mixed software-hardware implementation may be 
created. Each sender or receiver may be an item of pure hardware, or else a cpu with 
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circuitry and instructions capable of changing and/or sensing the appropriate signals (sr, 
rr, synch, data etc.). provided that the protocol is followed correctly (which is achieved 
usually by a finite state machine in the case of hardware, or by a program in the case of 
software) then the communicated data will be correctly transmitted. 

5 

If mchannels are to be used with the Bach system, then there must be an 
algorithm for creating the circuit from the source description, which is given below. 

Each process in Bach is implemented as a circuit, and a process which branches 
10 into subprocesses gives rise to more than one circuit. As an optimisation one 
subprocess branch may be subsumed within the parent process's circuit, while the others 
produce distinct circuits. To communicate between these circuits wires are used, or 
perhaps wires together with logic and storage (for example, for modelling shared 
variables and channels), and these are referred to as resources. This is more fully 
1 5 described in British Patent Publication No. 23 1 7245. 



The algorithm for creating the circuit from the source description is as follows. 
First, examine the source and discover which mchannels are declared. There will be 
one mchannel resource for each mchannel in the source, consisting of wires to and from 
20 the reading and writing circuits and a synchronisation block. For each mchannel, mch, 
determine how many receivers are required - there will be just one process containing 
send instructions for mch, and may be several processes containing receive instructions 
for mch. This information allows the synch blocks to be built, and connected in the 
appropriate way to the reading and writing circuits. 

25 

The invention can be used for a complex design with many almost-independent 
blocks, processing chunks of data in parallel without communication, but in 
synchronisation. A controller may communicate with the blocks to pass them 
configuration data on each cycle, by sending to an mchannel for which the blocks are all 
30 receivers. Using mchan means that all blocks will synchronise and change 
configuration together. Different mchans could be used to communicate with particular 
(pre-determined) subsets of the blocks. 
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The invention can also be used for system where a controller reads data from 
somewhere and passes it to a number of slaves which will each perform its own 
function on the data before reading the next block. If the controller sends data by 
mchannel then all the data processing is easily kept in step. 
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CLAIMS: 

1. A method of transferring data from a sender process to a plurality of receiver 
processes, wherein at least one of said processes is described in a hardware description 
language, said hardware description language incorporating simulation means for 
simulation of the behaviour of hardware and also incorporating a hardware compiler for 
deriving hardware which behaves according to said simulation, and wherein the method 
uses a language construct which effects synchronised communication between the 
sender process and the receiver processes. 

2. A method as claimed in Claim 1 which involves carrying out a send algorithm 
under the control of a pre-emptive scheduler. 



3. A method as claimed in claim 2 wherein the scheduler ensures that the send 
15 algorithm is carried out without descheduling. 



10 



4. A method as claimed in Claim 2 or 3, wherein a check is made that all of the 
receiver processes are ready to receive data before data is transferred from the sender 
process to the receiver processes. 

20 

5. A method as claimed in any preceding claim which involves carrying out a 
receive algorithm under the control of a pre-emptive scheduler. 

6. A method as claimed in Claim 5, wherein the scheduler ensures that the receive 
25 algorithm is carried out without descheduling. 

7. A method as claimed in any preceding claim, wherein at least one of said 
processes is embodied in hardware. 

30 8. A method as claimed in any of claims 1 to 6, wherein all of said processes are 
described in said hardware description language. 
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9. A synchronous electrical circuit produced by first simulating at least part of the 
circuit in accordance with the method of any preceding claim, and then creating the 
circuit using said hardware compiler. 

5 10. A synchronous electrical circuit as claimed in Claim 9, which is a digital 
electronic circuit. 



11. A hardware description language adapted to simulate the behaviour of at least a 
sender process and a plurality of receiver processes, and comprising a language 

10 construct which effects synchronised communication between the sender process and 
the receiver processes. 

12. A hardware description language adapted to carry out the method of any one of 
claims 1 to 8. 

15 
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ABSTRACT 
"Multichannel synchronised communication " 

A method is provided of transferring data from a sender process 2 to a plurality 
of receiver processes 4 in a hardware description language, which uses a language 
construct which effects synchronised communication between the sender process 2 and 
the receiver processes 4. 

(Figure 1(c)) 
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II 



sender:— senderU {(c/i, pid)} 

channeLready := channel Lready © {(c/i, {READY})} 




copy -data-to -destinations (data( ch),ch) 
wake-up(receivers(ch) — {pirf}) 

channeLready := channeLready® {(c/i, NOTREADY)} 
destinations := destinations® {(c/i, 0)} 
rfaia :— {c/i} ^c/aia; sender := {c/i} <3 sender 
receivers := {c/i} -^receivers; sleep{) 



unlock() 



Figure 2: Algorithm for send 
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lock() 



receivers receivers® {{ch, receivers(ch) U {pid})} 
destinations := destinations® {(ch, destinations (ch J U {y})} 




NO 



copy -data J,o -destinations ( data( ch),ch) 
wakejap(sender( ch)) 
wakejup(receivers(ch) — {pid}) 

channeLready := channel .ready © {(ch, NOTREADY)} 
destinations := destinations © {(c/i, 0)} 
daia := {c/i} ^ daia; sender := {c/i} <3 sender, 
receivers := {ch} < receivers; sleep () 




Figure 3: Algorithm for receive 
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lock() 



receivers :~ receivers® {(ch, receivers(ch) U {pid})} 




sleep () 



YES 



copy -data J,0-destinaiions{data{cK) , ch) 
destinations',— destinations® {(c/i,<£)} 
wake.up(sender( ch)) 
wake.up(receivers(ch) — {pid}) 

channeLready := channeLready © {(c/i, NOTREADY)} 
sender := {c/i} < sender, data := {c/i} -<3 daia 
receivers := {c/i} <3recezuers; sleepf) 



unlockf) 



Figure 4: Algorithm for the simplified receive 
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sender 








J ?vnch 







1. set 'data' to value to be sent 

2. set 'sr' to true 

3. wait until 'synch' is true 

4. set 'sr' to false 

Figure 5: Hardware implementation of send 
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synch 



A 



rr(i) 



Y 
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Receive: 



1. set 'rr(i)' to true 

2. wait until 'synch' is true 

3. copy data from 'data' 

4. set 'rr(i) ' to false 



Figure 6: Hardware implementation of receive 
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